For documentation purposes can you add to the PR description what the intended behavior is and what the incorrect behavior was

I’m actually gonna draw a hard line here. Yes, damo should have waited for any consensus to be reached before going ahead with this. When your whole team is going “wait this would be bad because xyz” you don’t go ahead with approval just because you personally think it “doesn’t feel that different”. Being head of balance means listening to balance team’s concerns. I’m aware there’s a lot going on right now so this may have flown under the radar, but that’s all the more reason to not approve+merge until proper attention can be given to it. That’s not the main issue here though.

We should NOT be approving much less merging PRs that don’t sufficiently document the changes within.

There is no clear indication within the pr description of what it does. It mentions a “fix” without stating what was fixed or what the issue was. “Actually works as intended” isn’t enough, you need to outline what the intended behavior was. Ideally before/after screenshots could be provided, though I understand this is a very small change to the code. The only hint of what the fix entails is in the testing section, but for all we know the intended behavior could just be “prioritize leftovers over anything else”. We already have an issue with lack of documentation on GitHub (Tapp was right moment?), and this pr being so incredibly nondescript only continues that trend.

Also, balance team, don’t be shy, comment on a PR if you object to it!

I would like this PR to be reverted.